With the development of informanization, the issues of malicious software such as virus and worms become very serious. At present, there have been over thirty-five thousand kinds of malicious software, and over forty million computers are infected every year. In order to astrict such attacks, not only secure transmission and check for data input need to be performed, but also defence should be performed from the source, i.e., each terminal connected to the network. However, conventional secure defence technologies can not defense various kinds of malicious attacks.
In view of this, the international Trusted Computing Group (TCG) has specially specified a network connect specification based on trusted computing technology—Trusted Network Connect (TNC), abbreviated as TCG-TNC. The TCG-TNC includes an open terminal integrity architecture and a set of standards for ensuring secure interoperation. The set of standards can protect a network to some extent as a user requires and customizes. The essential of the TCG-TNC is to set up a connection from the terminal integrity. First, a set of policies for operating in an internal system of the trusted network is created. Only terminals complying with the policies set by the network can access the network. The network isolates and locates those devices that do not comply with the policies. Due to the use of a Trusted Platform Module (TPM), an attack from root kits can be prevented further. Root bits is an attack script, a modified system program, or a whole set of attack scripts and tools, and is configured to obtain the highest control right of a target system illegally in the target system.
With the conventional TCG-TNC architecture, a procedure of information transmission over an overall the trusted network connection is as follows: before a network connection is set up, the TNC client needs to prepare required platform integrity information and to provide the required platform integrity information to the IMC. In a terminal including a trusted platform module, platform information required by network policies is hashed and stored in respective platform configuration registers (PCRs). The TNC Server needs to pre-specify verification requirements for the platform integrity and provides the verification requirements to the IMV. A detailed procedure is as follows:
(1) The network access requestor initiates an access request to the policy enforcer.
(2) The policy enforcer sends an access request description to a network access authority.
(3) The network access authority and the network access requestor perform a user authentication protocol on receiving the access request description from the network access requestor. If the user authentication is successful, the network access authority sends the access request and user authentication success information to the TNC server.
(4) The TNC server and the TNC client perform mutual platform credential authentication, e.g., verifying an Attestation Identity Key (AIK) of the platform, on receiving the access request and the user authentication success information from the network access authority.
(5) If the platform credential authentication is successful, the TNC client informs the IMC that a new network connection is initiated and an integrity handshake protocol should be performed. The IMC returns required platform integrity information via the IF-IMC interface. The TNC server sends the platform integrity information to the IMV via the IF-IMV interface.
(6) In a procedure of performing the integrity handshake protocol, the TNC client and the TNC server exchange data for one or more times until the TNC server is satisfied.
(7) When the TNC server accomplishes the integrity handshake protocol to the TNC client, the TNC server sends a recommendation letter to the network access authority to request for an access. In other consideration of securities, the policy decision point can still not allow the access of the access requestor.
(8) The network access authority transfers an access decision to the policy enforcer, which ultimately performs the decision to control the access of the access requestor.
At present, there is no mature TCG-TNC hierarchical product into the market. Some important technologies of the TCG-TNC architecture is still under research and specification and have the following disadvantages:
1. Bad extensibility. There are pre-defined secure channels between the policy enforcement point and the policy decision point and the policy decision point may possibly manage a plurality of policy enforcement points, which forces the policy decision point to configure a plurality of secure channels, thereby resulting in complexity of management. Therefore, the extensibility is bad.
2. Complex key negotiation procedure. Because security protection should be performed on data above the network access layer, secure channels need to be set up between the access requestor and the policy decision point, i.e., a session key negotiation is performed between them. However, data protection is also required between the access requestor and the policy enforcement point, a second session key negotiation is performed between the access requestor and the policy enforcement point, which makes the key negotiation procedure complex.
3. Relative poor security. A primary key negotiated between the access requestor and the policy decision point is transferred to the policy enforcement point by the policy decision point. The key is transferred over the network, which introduces new security attack points and reduces security. In addition, the same primary key is used in the two session key negotiations, which reduces the security of the whole trusted network connect architecture.
4. The access requestor possibly can not validate the AIK certificate of the policy decision point. In the procedure of platform credential authentication, the access requestor and the policy decision point utilize an AIK private key and certificate to perform the mutual platform credential authentication. Both of the access requestor and the policy decision point need to validate the AIK certificate. If the policy decision point is an on-line service provider of the access requestor, the access requestor can not access the network before a trusted network connection, i.e., can not validate the AIK certificate of the policy decision point, which results in insecurity.
5. Platform integrity evaluation is not peer-to-peer. In the TCG-TNC architecture, the policy decision point performs evaluation of platform integrity on the access requestor, however, the access requestor does not perform evaluation of platform integrity on the policy decision point. If the platform of the policy decision point is not trusted, it is insecure if the access requestor is connected to such an trusted device. However, peer trust is indispensable in a Ad hoc network.